+ private static boolean isASCII(byte[] ba, int off, int len) {+
for (int i = off; i < off + len; i++) {+ if (ba[i] <
0)+ return false;+ }+ return true;+ }
I see that StringCoding has
@HotSpotIntrinsicCandidate
public static boolean hasNegatives(byte[] ba, int off, int len) {
for (int i = off; i < off + len; i++) {
if (ba[i] < 0) {
return true;
}
}
return false;
}
and in hotspot-land I see that MacroAssembler::has_negatives has 200 lines
of hairy assemblerese. Let's reuse that enormous effort! And not just in
ZipCoder.java - needing to check a byte sequence for Ascii-ness is a bit
goofy but important enough to be a public API (I've used optimized
versions of this in other languages). I don't know where it belongs (could
add a method to CharsetDecoder, intrinsified for US_ASCII), but we can find
one. Even without that, surely today we should be able to reuse this
intrinsic from somewhere else within the java.base module.
(Keeping high-performance intrinsics hidden is a top reason why java
developers use jdk internals)
(Not directed at Xueming in particular)
