Thank you, Paul, Remi, Anthony, for reviews.
I changed "protected final" to "private" as suggested:
http://cr.openjdk.java.net/~kvn/8035974/webrev.01
Note, JIT inlines final and private methods without generation a
method's class check. So inlined code is the same.
Thanks,
Vladimir
On 5/23/14 10:27 AM, james cheng wrote:
On 5/23/2014 3:17 AM, Remi Forax wrote:
On 05/23/2014 11:06 AM, Paul Sandoz wrote:
On May 22, 2014, at 1:34 AM, Vladimir Kozlov
<vladimir.koz...@oracle.com> wrote:
http://cr.openjdk.java.net/~kvn/8035974/webrev
https://bugs.openjdk.java.net/browse/JDK-8035974
Contributed by James Cheng and modified by me.
Looks good to me.
Paul.
implCompressMultiBlock should be private thus don't need to be final.
Rémi
I pulled it out of engineUpdate() so kept it "protected final" as
before. I
just tried it with "private" and it still could be intrinsified. So
either way
is okay in terms of intrinsification.
Thanks,
-James
To use intrinsics to accelerate SHA operations on multiple blocks
[1], it is needed to pull a loop out of DigestBase.engineUpdate()
and make a new method
implCompressMultiBlock() which contains only the loop and can be
intrinsified.
On platforms which does not use intrinsic implCompressMultiBlock()
method will be inlined by JIT and the same code will be generated as
before. So no performance
regression with the pure Java SUN provider is expected.
About arithmetic change. limit = ofs + len will not overflow integer
because ofs <= b.length - len (there is check).
Tested with jdk jtreg tests and new hotspot jtreg test James wrote
for 8035968.
Thanks,
Vladimir
[1] https://bugs.openjdk.java.net/browse/JDK-8035968
