Please help review the change for JDK-819798
The change for JDK-8164278 caused a decoding regression. A Tier2
test case, javax/net/ssl/interop/ClientHelloChromeInterOp.java, that
uses mime-base64-decoder failed.
The "condition" that triggers the decoding to go the fast path is
the code pushed for JDK-819798.
The intent here is to only start/try the fast path when we are at the
of a 4-byte legal base64 unit. The correct/appropriate check is to see if
shiftto == 18, which means the decoder is still at the beginning of 4-byte
unit. ( bits == 0 is a false indicator, as bits might include decoded
byte value of
0). The fix is a relatively easy/one line change.