RFR (S) 8035974: Refactor DigestBase.engineUpdate() method for better code generation by JIT compiler

[Vladimir Kozlov]

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.kozlov at 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
>>