RFR(L): 8035936: SIGBUS in StubRoutines::aesencryptBlock, solaris-sparc
Shrinivas Joshi
shrinivas.joshi at oracle.com
Wed Apr 30 06:07:43 UTC 2014
Thanks very much for your help, Vladimir.
-Shrinivas
On 4/29/2014 10:31 PM, Vladimir Kozlov wrote:
> Looks good. I will push it tomorrow.
>
> thanks,
> Vladimir
>
> On 4/29/14 7:48 PM, Shrinivas Joshi wrote:
>> Hi Vladimir,
>>
>> I have made the CBCond based branches change that you recommended. I
>> would appreciate if you could take another look at
>> these changes - http://cr.openjdk.java.net/~kvn/8035936/webrev.01/
>>
>> Thanks,
>> -Shrinivas
>>
>> On 4/28/2014 3:25 PM, Vladimir Kozlov wrote:
>>> Hi Joshi,
>>>
>>> In several places I see unconditional branch with nop in delay slots:
>>>
>>> + __ br(Assembler::always, true, Assembler::pt,
>>> L_load_expanded_key);
>>> + __ delayed()->nop();
>>>
>>> Why you did not use cbcond (when distance is small) since AES will
>>> be used only on T4 and newer cpus?:
>>>
>>> __ ba_short(L_load_expanded_key);
>>>
>>> There are other short branches variants.
>>>
>>> In general changes are good.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 4/25/14 5:45 PM, Shrinivas Joshi wrote:
>>>> Hi,
>>>>
>>>> Requesting reviews for the following change. Thanks for your time.
>>>>
>>>> -Shrinivas
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8035936
>>>> Webrev: http://cr.openjdk.java.net/~kvn/8035936/webrev/
>>>>
>>>> Summary: The intrinsified AES encryption and decryption JDK API
>>>> methods
>>>> take byte arrays and offsets into these arrays as input arguments.
>>>> Thus
>>>> the stub routines can potentially read from and write to arbitrarily
>>>> aligned addresses. SPARC load/store instructions generate
>>>> 'mem_address_not_aligned' exception when they operate on improperly
>>>> aligned addresses. This change addresses the arbitrary alignment issue
>>>> in case of SPARC AES crypto stub routines.
>>>>
>>>> Summary of source code changes:
>>>>
>>>> * src/cpu/sparc/vm/assembler_sparc.hpp:
>>>> - Added support for ALIGNADDR(Align Address), FALIGNDATA(Align
>>>> Data
>>>> using GSR.align), EDGE8N(Edge Handling Instructions), FSRC2(F Register
>>>> Logical Operate) and STPARTIALF(Store Partial Floating-Point)
>>>> instructions
>>>>
>>>> * src/cpu/sparc/vm/stubGenerator_sparc.cpp:
>>>> - Added assertion checks to test if first element of 'int' and
>>>> 'byte' arrays are at 8-byte aligned address. HotSpot's current object
>>>> layout guarantees this.
>>>> - Changed single-block encrypt and decrypt stub routine names to
>>>> match with what is used on x86.
>>>> - Added code to address mis-aligned loads and stores. Added some
>>>> details on the methodology used to address mis-aligned load/store
>>>> instructions (in form of comments).
>>>> - Since we are now explicitly testing 8-byte alignment, we are now
>>>> using 8-byte FP load/store instructions instead of the 2*4-bytes and a
>>>> FMOV instruction as was done previously.
>>>> - Single-block decrypt routine now uses a lower latency FSRC2d
>>>> instruction instead of the more expensive FMOVd instruction.
>>>> - Multi-block (CBC) encrypt routine now does a save-restore to
>>>> ease
>>>> register pressure due to mis-alignment related code.
>>>> - CBC encrypt routine uses G5 instead of G2 register.
>>>> - During mis-aligned stores in CBC encrypt, we also have to
>>>> save and
>>>> reload cipher text (in F60:F62) so that it is saved in the correct
>>>> byte
>>>> order in the initialization vector which is then fed back into
>>>> encryption of the next block. This is done by MOVdTOx and MOVxTOd
>>>> instructions.
>>>>
>>>> * src/cpu/sparc/vm/stubRoutines_sparc.hpp:
>>>> - Increased code buffer blob size for stub routines as the current
>>>> size of 20000 is not sufficient after addition of mis-alignment
>>>> related
>>>> code.
>>>>
>>>> * src/cpu/sparc/vm/vm_version_sparc.cpp:
>>>> - Updated comments to reflect that AES instructions are available
>>>> starting SPARC T4, previously it was incorrectly stated as T2.
>>>> - Updated AES intrinsics flag value sanity checks to include VIS3
>>>> instruction capability instead of only VIS1 since VIS3
>>>> instructions(MOVdTOx, MOVxTod) are also used by AES stubs.
>>>>
>>>> * src/share/vm/classfile/vmSymbols.hpp and
>>>> src/share/vm/opto/runtime.cpp
>>>> - typo fixes
>>>>
>>>> * test/compiler/7184394/TestAESBase.java
>>>> - Added code to exercise mis-aligned loads and stores.
>>>> - Made padding string a property that can be passed on
>>>> command-line
>>>> since certain alignment issues are not triggered with padding enabled.
>>>> - If any of the alignment cases (encryption input, encryption
>>>> output/decryption input and decryption output) are being tested
>>>> then the
>>>> test case now does multi-part crypto operations with an update()
>>>> followed by doFinal(). We need to do this because certain alignment
>>>> issues are not triggered when only doFinal() calls are used. If
>>>> mis-alignment is not being tested then the test case excercises
>>>> single-part operations as was the case previously.
>>>> - In case of multi-part operations, the last chunk of input passed
>>>> to encryption/decryption routines is set to 2*blocks long. This is
>>>> again
>>>> because mis-aligned stores during decryption are not triggered if
>>>> input
>>>> is less than 2*blocks long.
>>>>
>>>> * test/compiler/7184394/TestAESDecode.java and
>>>> test/compiler/7184394/TestAESEncode.java:
>>>> - Exercises mulit-part mis-aligned operations when
>>>> mis-alignment is
>>>> being tested
>>>>
>>>> * test/compiler/7184394/TestAESMain.java:
>>>> - Added new @run commands to include various mis-aligned cases.
>>>> - warm-up iterations count is now configurable.
>>>
>>>
>>
>
>
More information about the hotspot-compiler-dev
mailing list