8173585: Intrinsify StringLatin1.indexOf(char)

[ghost]

This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as code for C2.

Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and java/lang/StringLatin1.java

https://bugs.openjdk.java.net/browse/JDK-8173585

Details of testing:

I have created a jtreg test “compiler/intrinsics/string/TestStringLatin1IndexOfChar” to cover this new intrinsic. Note that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the input String. Hence the test has been designed to cover all these cases. In summary they are:

• A “short” string of < 16 characters.
• A SIMD String of 16 – 31 characters.
• A AVX2 SIMD String of 32 characters+.

Hardware used for testing:

• Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) • Intel i7 processor (with AVX2 support).
• AWS Graviton 2 (ARM 64 processor).

I also ran; ‘run-test-tier1’ and ‘run-test-tier2’ for: x86_64 and aarch64.

Possible future enhancements:

For the x86 implementation there may be two further improvements we can make in order to improve performance of both the StringUTF16 and StringLatin1 indexOf(char) intrinsics:

1. Make use of AVX-512 instructions.
2. For “short” Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD instructions instead of a loop.

Benchmark results:

Without the new StringLatin1 indexOf(char) intrinsic:

Benchmark	Mode	Cnt	Score	Error	Units
IndexOfBenchmark.latin1_mixed_char	avgt	5	26,389.129	± 182.581	ns/op
IndexOfBenchmark.utf16_mixed_char	avgt	5	17,885.383	± 435.933	ns/op

With the new StringLatin1 indexOf(char) intrinsic:

Benchmark	Mode	Cnt	Score	Error	Units
IndexOfBenchmark.latin1_mixed_char	avgt	5	17,875.185	± 407.716	ns/op
IndexOfBenchmark.utf16_mixed_char	avgt	5	18,292.802	± 167.306	ns/op

The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when running on ARM.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8173585: Intrinsify StringLatin1.indexOf(char)

Reviewers

• Nils Eliasson (@neliasso - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/71/head:pull/71
$ git checkout pull/71

[bridgekeeper]

Hi @jasontatton-aws, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user jasontatton-aws" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

[openjdk]

@jasontatton-aws The following labels will be automatically applied to this pull request: core-libs hotspot.

When this pull request is ready to be reviewed, an RFR email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label (add|remove) "label" command.

[ghost]

/covered

[bridgekeeper]

Thank you! Please allow for a few business days to verify that your employer has signed the OCA. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

[mlbridge]

Webrevs

• 05: Full - Incremental (3ae1d92)
• 04: Full - Incremental (8ead02a)
• 03: Full - Incremental (c8a2849)
• 02: Full - Incremental (c8cc441)
• 01: Full (b85a7fb)
• 00: Full (5f1ff76)

[mlbridge]

Mailing list message from Andrew Haley on hotspot-dev:

On 11/09/2020 11:23, Jason Tatton wrote:

For the x86 implementation there may be two further improvements we
can make in order to improve performance of both the StringUTF16 and
StringLatin1 indexOf(char) intrinsics:

1. Make use of AVX-512 instructions.

Is this really a good idea?

When the processor detects Intel AVX instructions, additional
voltage is applied to the core. With the additional voltage applied,
the processor could run hotter, requiring the operating frequency to
be reduced to maintain operations within the TDP limits. The higher
voltage is maintained for 1 millisecond after the last Intel AVX
instruction completes, and then the voltage returns to the nominal
TDP voltage level.

https://computing.llnl.gov/tutorials/linux_clusters/intelAVXperformanceWhitePaper.pdf

So, if StringLatin1.indexOf(char) executes enough to make a difference
to any real-world program, the effect may well be to slow down the clock
for all of the code that does not use AVX.

2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD
instructions instead of a loop.

--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

[mlbridge]

Mailing list message from Tatton, Jason on hotspot-dev:

Hi Everyone,

Please could some reviewers volunteer their time to have a look at this patch?

It was marked as a starter bug so I don't expect it will consume a lot of time.

Thanks,
Jason

-----Original Message-----
From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> On Behalf Of Jason Tatton
Sent: 11 September 2020 11:24
To: core-libs-dev at openjdk.java.net; hotspot-dev at openjdk.java.net
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char)

This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for
x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as code for C2.

Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and java/lang/StringLatin1.java

https://bugs.openjdk.java.net/browse/JDK-8173585

Details of testing:
============
I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the input String. Hence the test has been designed to cover all these cases. In summary they are:

- A ?short? string of < 16 characters.
- A SIMD String of 16 ? 31 characters.
- A AVX2 SIMD String of 32 characters+.

Hardware used for testing:
-----------------------------

- Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support).
- AWS Graviton 2 (ARM 64 processor).

I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64.

Possible future enhancements:
====================
For the x86 implementation there may be two further improvements we can make in order to improve performance of both the StringUTF16 and StringLatin1 indexOf(char) intrinsics:

1. Make use of AVX-512 instructions.
2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD instructions instead of a loop.

Benchmark results:
============
**Without** the new StringLatin1 indexOf(char) intrinsic:

| Benchmark | Mode | Cnt | Score | Error | Units |
| ------------- | ------------- |------------- |-------------
| |------------- |------------- | IndexOfBenchmark.latin1_mixed_char |
| avgt | 5 | **26,389.129** | ? 182.581 | ns/op |
| IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933
| | ns/op |

**With** the new StringLatin1 indexOf(char) intrinsic:

| Benchmark | Mode | Cnt | Score | Error | Units |
| ------------- | ------------- |------------- |-------------
| |------------- |------------- | IndexOfBenchmark.latin1_mixed_char |
| avgt | 5 | **17,875.185** | ? 407.716 | ns/op |
| IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306
| | ns/op |

The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16
indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when running on ARM.

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

Commit messages:
- 8173585: further whitespace changes required by jcheck
- JDK-8173585 - whitespace changes required by jcheck
- JDK-8173585

Changes: https://git.openjdk.java.net/jdk/pull/71/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=71&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8173585
Stats: 522 lines in 15 files changed: 506 ins; 0 del; 16 mod
Patch: https://git.openjdk.java.net/jdk/pull/71.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/71/head:pull/71

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

[ghost]

Hi Andrew, The current indexOf char intrinsics for StringUTF16 and the new one here for StringLatin1 both use the AVX2 – i.e. 256 bit instructions, these are also affected by the frequency scaling which affects the AVX-512 instructions you pointed out. Of course in a world where all the work taking place is AVX instructions this wouldn’t be an issue but in mixed mode execution this is a problem. However, the compiler does have knowledge of the capability of the CPU upon which it’s optimizing code for and is able to decide whether to use AVX instructions if they are supported by the CPU AND if it wouldn’t be detrimental for performance. In fact, there is a flag which one can use to interact with this: -XX:UseAVX=version. This of course made testing this patch an interesting experience as the AVX2 instructions were not enabled on the Xeon processors which I had access to at AWS, but in the end I was able to use an i7 on my corporate macbook to validate the code. From: mlbridge[bot] <notifications@github.com> Sent: 11 September 2020 17:01 To: openjdk/jdk <jdk@noreply.github.com> Cc: Tatton, Jason <jptatton@amazon.com>; Mention <mention@noreply.github.com> Subject: Re: [openjdk/jdk] 8173585: Intrinsify StringLatin1.indexOf(char) (#71) Mailing list message from Andrew Haley<mailto:aph@redhat.com> on hotspot-dev<mailto:hotspot-dev@openjdk.java.net>: On 11/09/2020 11:23, Jason Tatton wrote: For the x86 implementation there may be two further improvements we can make in order to improve performance of both the StringUTF16 and StringLatin1 indexOf(char) intrinsics: 1. Make use of AVX-512 instructions. Is this really a good idea? When the processor detects Intel AVX instructions, additional voltage is applied to the core. With the additional voltage applied, the processor could run hotter, requiring the operating frequency to be reduced to maintain operations within the TDP limits. The higher voltage is maintained for 1 millisecond after the last Intel AVX instruction completes, and then the voltage returns to the nominal TDP voltage level. https://computing.llnl.gov/tutorials/linux_clusters/intelAVXperformanceWhitePaper.pdf So, if StringLatin1.indexOf(char) executes enough to make a difference to any real-world program, the effect may well be to slow down the clock for all of the code that does not use AVX. 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD instructions instead of a loop.

…

-- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#71 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQ44AL33DFEQ36TCHSTZKCLSFJCUJANCNFSM4Q74AKCQ>.

[dholmes-ora]

/label add hotspot-compiler

[openjdk]

@dholmes-ora
The hotspot-compiler label was successfully added.

[mlbridge]

Mailing list message from Andrew Haley on hotspot-dev:

On 12/09/2020 00:06, Jason Tatton wrote:

The current indexOf char intrinsics for StringUTF16 and the new one
here for StringLatin1 both use the AVX2 ? i.e. 256 bit instructions,
these are also affected by the frequency scaling which affects the
AVX-512 instructions you pointed out. Of course in a world where all
the work taking place is AVX instructions this wouldn?t be an issue
but in mixed mode execution this is a problem.

Right.

However, the compiler does have knowledge of the capability of the
CPU upon which it?s optimizing code for and is able to decide
whether to use AVX instructions if they are supported by the CPU AND
if it wouldn?t be detrimental for performance. In fact, there is a
flag which one can use to interact with this: -XX:UseAVX=version.

Sure. But the question to be answered is this: we can use AVX for
this, but should we? "It's there, so we should use it" isn't sound
reasoning.

My guess is that there are no (non-FP) workloads where AVX dominates.
And that therefore throwing AVX at trivial jobs may make our programs
slower; this is a pessimization.

I have to emphahsize that I don't know the answer to this question.

This of course made testing this patch an interesting experience as
the AVX2 instructions were not enabled on the Xeon processors which
I had access to at AWS, but in the end I was able to use an i7 on my
corporate macbook to validate the code.

So: is this worth doing? Are there workloads where this helps? Where
this hinders? This is the kind of systems thinking we should be doing
when optimizing.

--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

[ghost]

Hi everyone,

This patch is just missing a couple of reviewers... Please can someone step forward?

I think it's a fairly straightforward change.

-Jason

[mlbridge]

Mailing list message from Andrew Dinn on hotspot-dev:

On 17/09/2020 19:22, Jason Tatton wrote:

This patch is just missing a couple of reviewers... Please can someone step forward?

I think it's a fairly straightforward change.

I believe you got a review from Andrew Haley -- it was quoted in your
follow-up from which I selected the above response.

What you did not get was license to proceed and push this change. That's
because what is actually missing is the justification he asked for. As
Andrew pointed out the change is simple but the reason for implementing
it is not.

regards,

Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill

[openjdk]

@jasontatton-aws this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout JDK-8173585
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

[ghost]

Hi Andrew,

Thanks for coming back to me. Looking on the github PR nobody is tagged as a reviewer for this (perhaps this is a feature which is not being used).

That's
because what is actually missing is the justification he asked for. As
Andrew pointed out the change is simple but the reason for implementing
it is not.

There are two separate things here:
1). Justification for the change itself:
-The objective and justification for this patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 indexOf(char) for x86 and ARM64. This solves the problem as raised in JDK-8173585, and also on the mailing list.

2). Discussion around future enhancements - concerning potential use of AVX-512 instructions and a more optimal implementation for short strings.
-These would be separate JBS's I'm not advocating for/against this, they are just ideas separate from this JBS.

[vnkozlov]

Based on comment by @jatin-bhateja (Intel) frequency level switchover pointed by @theRealAph is sensitive to vector size
#144 (comment)

By keeping vector size less or equal to 32 bytes we should avoid it. And as I can see this intrinsic code is using 32 bytes (chars) and 16 bytes vectors: pbroadcastb(vec1, vec1, Assembler::AVX_256bit);

Also we never had issues with AVX2. only with AVX512 regarding performance hit:
https://bugs.openjdk.java.net/browse/JDK-8221092

I would like to see performance numbers for for all values of UseAVX flag : 0, 1, 2, 3

The usage is guarded UseSSE42Intrinsics in UseSSE42Intrinsics predicate in .ad file. Make sure to test with UseAVX=0 to make sure that some avx instructions are not mixed into non avx code. And also with UseSSE=2 (for example) to make sure shared code correctly recognize that intrinsics is not supported.

[adinn]

@vnkozlov @mknjc @jatin-bhateja Thanks for providing the relevant details. I'm now quite content that this patch avoids any potential frequency scaling problem. I'm also glad that an explanation of why this is so is now available -- although it's not perfect that we are relying on a stackoverflow post for the full details.

[simonis]

Hi Jason,

thanks for bringing String.indexOf() for latin strings up to date with the Unicode version.

Your changes look good except a few minor issues I've commented on right in the code.

I'd only like to ask you if you could possibly improve your test a little bit. As far as I understand, your search text is a consecutive sequence of "abc" characters, so you'll always find the character your searching for within the next three characters of the source text. This won't exercise the loops of your intrinsic. Maybe you can also add some test versions where the search character will be found beyond the first 32/64 characters after "fromIndex"?

[ghost]

@simonis Thank you for the corrections, I have ammended them in the latest comit as follows:

Changes to unit test:

• main test adjusted such that Strings gennerated are much longer (up to 2048 characters) and of the form: azaza, aazaazaa, aaazaaazaaa, etc with 'z' being the search character searched for. Multiple instances of the search character are included in the String in order to validate that the starting offset is correctly handleded. Results are compared to non intrinsified version of the code. Longer strings means that the looping functionality of the various paths is entered into.
• Run configurations introduced such that it checks behaviour where use of SSE and AVX instructions are restricted.
• Tier4InvocationThreshold adjusted so as to ensure C2 code iis invoked.

Other changes:

• newlines added at end of files

@vnkozlov here are the performance numbers as requested. I have included performance of the UTF16 version of the intrinsic for reference:

UseAVX=	UseSSE=	Benchmark	Mode	Cnt	Score	Error	Units
	0	IndexOfBenchmark.latin1_long_char	avgt	5	447,493.398	± 4,666.386	ns/op
0		IndexOfBenchmark.latin1_long_char	avgt	5	104,735.941	± 2,484.403	ns/op
1		IndexOfBenchmark.latin1_long_char	avgt	5	104,342.844	± 2,656.343	ns/op
2		IndexOfBenchmark.latin1_long_char	avgt	5	61,000.418	± 1,543.951	ns/op
3		IndexOfBenchmark.latin1_long_char	avgt	5	60,607.988	± 1,466.354	ns/op
	0	IndexOfBenchmark.utf16_long_char	avgt	5	672,475.302	± 4,998.596	ns/op
0		IndexOfBenchmark.utf16_long_char	avgt	5	175,521.654	± 7,549.094	ns/op
1		IndexOfBenchmark.utf16_long_char	avgt	5	172,514.981	± 3,561.040	ns/op
2		IndexOfBenchmark.utf16_long_char	avgt	5	120,725.748	± 2,004.400	ns/op
3		IndexOfBenchmark.utf16_long_char	avgt	5	120,664.623	± 1,988.419	ns/op

I think the results are as expected, we see improvements in performance as the range of SSE and AVX instructions which can be used is expanded upon. Note that no improvement is observed with UseAVX=3 because there is no AVX-512 code in these intrinsics.

[ghost]

Hi All,

Just wondering if there is anything you'd like me to do in order to assist with moving this patch forward?

Thanks,
Jason

[vnkozlov]

Changes seems fine but you missing Copyright + GPL header in new files.

[openjdk]

⚠️ @jasontatton-aws the full name on your profile does not match the author name in this pull requests' HEAD commit. If this pull request gets integrated then the author name from this pull requests' HEAD commit will be used for the resulting commit. If you wish to push a new commit with a different author name, then please run the following commands in a local repository of your personal fork:

$ git checkout JDK-8173585
$ git commit -c user.name='Preferred Full Name' --allow-empty -m 'Update full name'
$ git push

[openjdk]

@jasontatton-aws This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8173585: Intrinsify StringLatin1.indexOf(char)

Reviewed-by: neliasso

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 349 new commits pushed to the master branch:

• ba140b0: 8254748: Bad Copyright header format after JDK-8212218
• db9dcdf: 8254668: JVMTI process frames on thread without started processing
• dc262df: 8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out
• 9eeeb8a: 8254696: safepointMechanism_aix needs adaptation for JDK-8253180
• b509e31: 8254602: compiler/debug/TestStressCM.java failed with "RuntimeException: got the same optimization stats for different seeds: expected 45"
• 9fe9b24: 8254575: C2: Clean up unused TRACK_PHI_INPUTS assertion code
• 31d9b7f: 8254252: Generic arraycopy stub overwrites callee-save rdi register on 64-bit Windows
• a098037: 8254365: ciMethod.hpp should not include methodHandles.hpp
• d50e0de: 8254722: bsd_zero builds broken after JDK-8253717
• ba5dc67: 8254158: Consolidate per-platform stack overflow handling code
• ... and 339 more: https://git.openjdk.java.net/jdk/compare/83b2411fd15d0890042ede118a08731ca162b951...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@simonis, @vnkozlov, @neliasso) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[ghost]

/integrate

[openjdk]

@jasontatton-aws
Your change (at version 3ae1d92) is now ready to be sponsored by a Committer.

[phohensee]

/sponsor

[openjdk]

@phohensee @jasontatton-aws Since your change was applied there have been 350 commits pushed to the master branch:

• 95e68c6: 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp
• ba140b0: 8254748: Bad Copyright header format after JDK-8212218
• db9dcdf: 8254668: JVMTI process frames on thread without started processing
• dc262df: 8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out
• 9eeeb8a: 8254696: safepointMechanism_aix needs adaptation for JDK-8253180
• b509e31: 8254602: compiler/debug/TestStressCM.java failed with "RuntimeException: got the same optimization stats for different seeds: expected 45"
• 9fe9b24: 8254575: C2: Clean up unused TRACK_PHI_INPUTS assertion code
• 31d9b7f: 8254252: Generic arraycopy stub overwrites callee-save rdi register on 64-bit Windows
• a098037: 8254365: ciMethod.hpp should not include methodHandles.hpp
• d50e0de: 8254722: bsd_zero builds broken after JDK-8253717
• ... and 340 more: https://git.openjdk.java.net/jdk/compare/83b2411fd15d0890042ede118a08731ca162b951...master

Your commit was automatically rebased without conflicts.

Pushed as commit f71e8a6.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

[RogerRiggs]

Due to the requirement for multiple reviewers, I had been waiting to add my review of the Core-Libs files until the HotSpot reviewers had approved! I see only one reviewer credited in the commit.

[RogerRiggs]

This integration without testing with a current merge from the master and has caused two build failures.

JDK-8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar

JDK-8254775: Microbenchmark StringIndexOfChar doesn't compile

There is a raw unicode character in the JMH test that causes a compilation error.

[2020-10-14T14:39:09,608Z] * For target support_test_micro_classes__the.BUILD_JDK_MICROBENCHMARK_batch:
[2020-10-14T14:39:09,611Z] /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71: error: unmappable character (0xE2) for encoding ascii
[2020-10-14T14:39:09,611Z]             sb.append(isUtf16?'???':'b');
[2020-10-14T14:39:09,611Z]                                ^
[2020-10-14T14:39:09,611Z] /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71: error: unmappable character (0x98) for encoding ascii
[2020-10-14T14:39:09,611Z]             sb.append(isUtf16?'???':'b');
[2020-10-14T14:39:09,611Z]                                 ^
[2020-10-14T14:39:09,611Z] /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71: error: unmappable character (0xBA) for encoding ascii
[2020-10-14T14:39:09,611Z]             sb.append(isUtf16?'???':'b');
[2020-10-14T14:39:09,611Z]                                  ^
[2020-10-14T14:39:09,611Z] /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71: error: unclosed character literal
[2020-10-14T14:39:09,611Z]             sb.append(isUtf16?'???':'b');
[2020-10-14T14:39:09,611Z]                               ^
[2020-10-14T14:39:09,611Z] /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71: error: unclosed character literal
[2020-10-14T14:39:09,611Z]             sb.append(isUtf16?'???':'b');```

[RogerRiggs]

And also a failed Graal test because of the new intrinsic.

And JDK-8254785: compiler/graalunit/HotspotTest.java failed with "missing Graal intrinsics for: java/lang/StringLatin1.indexOfChar([BIII)I"

@phohensee don't be so quick to type /sponsor; there are three separate build and test failures.

[dcubed-ojdk]

@phohensee - @vnkozlov has determined that a new Tier2 test failure is
also caused by this fix. See https://bugs.openjdk.java.net/browse/JDK-8254790.