RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v9]

[Lutz Schmidt]

On Thu, 3 Mar 2022 12:45:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>>     * There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>> 
>> I'm not sure that we can disregard such cases. You're probably right, but it'd be interesting to know the actual cause of the problem, perhaps with perfasm. Or do you know already?
>
>> > ```
>> > * There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>> > ```
>> 
>> I'm not sure that we can disregard such cases. You're probably right, but it'd be interesting to know the actual cause of the problem, perhaps with perfasm. Or do you know already?
> 
> Still looking into it in detail, but the shape of the code at the bytecode level is different, so generated code looks quite different, which means the logical branches can be laid out differently, or just placed in a different order. The 5% in this particular test could easily be due to getting a different order of the tests for determining if a byte is ascii or latin1. 
> 
> I'm also in the process of measuring in detail after narrowing down the `bottom_type()` of the intrinsic and a few other recent fixes that could affect code generation in C2. Will also benchmark on aarch64 and report back.

> > @cl4es Looks like you forgot to remove the "@IntrinsicCandidate" annotation for has_negatives.
> 
> I was going back and forth ...

Well, it just didn't build. With the annotation being present, you also need an intrinsic implementation. That's what the error message is saying...

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

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