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

[Claes Redestad]

On Tue, 15 Feb 2022 11:20:55 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> Well, with the existing implementations for ppc and s390, I do not see a complexity advantage with a relaxed spec. The code would have to be there anyway.

Same for x86, but we could avoid going into and checking the tail on a negative byte in a vector and instead an early return that returns `N * vector_size` where `N` is the number of vectors we've checked that were all positive. This could save a few ns in some cases.

> 
> When it comes to cost, the worst case would be an array of length n, a loop unroll factor of (u==n) and the first (and only) negative byte at index (n-1). All bytes would then be checked twice. With growing n, the overhead diminishes. After all, you want profile-based stub generation - with actual load matching the profile, of course.

Sounds about right. I've explored the cost of this in a few microbenchmarks. In `StringDecode/-Encode` such double-checking would happen anyhow later on in the java code. So for most of the prominent use such double-checking is performance neutral even in the worst case. 

There are a few places where we don't productively use the count and continue to lean on a `hasNegatives` predicate which calls into `countPositives`. This will mean a small amount of useless computation on certain inputs. For the 16- and 32-byte vectors I've benchmarked extensively on x86 (AVX2) the worst case overhead landed in the vicinity of 20 cycles (7.5-15ns @ 2.4Ghz). Allowing for imprecision _could_ improve a few such corner cases, but I've not found a performance sensitive place where it would really matter.

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

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