RFR: 8251152: ARM32: jtreg c2 Test8202414 test crash
Igor Ignatyev
igor.ignatyev at oracle.com
Fri Sep 4 14:25:15 UTC 2020
Hi Filipp,
> On Sep 4, 2020, at 12:46 AM, Filipp Zhinkin <filipp.zhinkin at gmail.com> wrote:
>
> Hi,
>
> updated webrev: http://cr.openjdk.java.net/~bulasevich/fzhinkin/8251152/webrev.2/ <http://cr.openjdk.java.net/~bulasevich/fzhinkin/8251152/webrev.2/> (I've updated years in the copyright).
I don't know the format used in SAP copyright notices, so I can't really tell if you should have added ", 2020" there, this I'd suggest you to seek comments from SAP folks.
> IIRC it's enough to have only one reviewer for such a small change, right?
right, one reviewer is sufficient for "trivial" changes, but as I said I can't really review changes in SAP copyright line.
Cheers,
-- Igor
>
> Thanks,
> Filipp.
>
>
> On Wed, 2 Sep 2020 at 21:53, Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
>
>
>> On Sep 2, 2020, at 1:06 AM, Filipp Zhinkin <filipp.zhinkin at gmail.com <mailto:filipp.zhinkin at gmail.com>> wrote:
>>
>> Hi,
>>
>> updated webrev: http://cr.openjdk.java.net/~bulasevich/fzhinkin/8251152/webrev.1/ <http://cr.openjdk.java.net/~bulasevich/fzhinkin/8251152/webrev.1/>
>>
>> Tests are throwing SkippedException now, as Igor suggested.
> thanks, LGTM.
>
>> Seems like I should also update a year in JdkInternalMiscUnsafeUnalignedAccess' copyright, but I'm not sure if there should be a line designating Oracle as intellectual property owner along with SAP. Should I add it too?
> IANAL, but unless the file was modified by Oracle, it doesn't have to have Oracle copyright notice.
>
> Thanks,
> -- Igor
>>
>> Thanks,
>> Filipp.
>>
>> On Tue, 1 Sep 2020 at 22:48, Filipp Zhinkin <filipp.zhinkin at gmail.com <mailto:filipp.zhinkin at gmail.com>> wrote:
>> Hi Igor,
>>
>> On Tue, 1 Sep 2020 at 19:46, Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
>> Hi Filipp,
>>
>> 1st of all, welcome back!
>>
>> thanks!
>>
>>
>> it would be better to throw jtreg.SkippedException at L#46 so jtreg will reported the test as skipped (as opposed to just passed).
>> Thanks, I'll update Test8202414 as well as compiler/unsafe/JdkInternalMiscUnsafeUnalignedAccess (which also skips execution the same way).
>>
>> alternative, you could use '@requires vm.simpleArch != "arm"' to exclude the test from arm32 execution.
>>
>> I was thinking about adding something like vm.unalignedAccess.enabled, but it seems to be too complicated solution for two tests (Test8202414 and compiler/unsafe/JdkInternalMiscUnsafeUnalignedAccess).
>> I don't want to use 'simpleArch', because if some new platform missing unaligned access support will be added in the future then someone will have to spend time to find out why a test crashes.
>>
>> Thanks,
>> Filipp.
>>
>>
>> Thanks,
>> -- Igor
>>
>>
>> > On Sep 1, 2020, at 8:29 AM, Filipp Zhinkin <filipp.zhinkin at gmail.com <mailto:filipp.zhinkin at gmail.com>> wrote:
>> >
>> > Hi,
>> >
>> > Test8202414 crashes on ARM32 while writing to memory using an unaligned
>> > address.
>> > ARM32 supports unaligned memory accesses for some load/store instructions
>> > under certain conditions, but LDRD (which is used when we're calling
>> > Unsafe::putLong) is always causing alignment fault when called with an
>> > unaligned address [1].
>> >
>> > The fix is simply skipping the test execution if a platform does not
>> > support unaligned memory accesses.
>> >
>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8251152 <https://bugs.openjdk.java.net/browse/JDK-8251152>
>> > Webrev: http://cr.openjdk.java.net/~bulasevich/fzhinkin/8251152/webrev.0/ <http://cr.openjdk.java.net/~bulasevich/fzhinkin/8251152/webrev.0/>
>> >
>> > [1] ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition, §A3.2.1
>> > Unaligned data access https://developer.arm.com/documentation/ddi0406/cd <https://urldefense.com/v3/__https://developer.arm.com/documentation/ddi0406/cd__;!!GqivPVa7Brio!LmT9wbXnxT5H1XrOZaO8lKj3bT1acuEZPfqS39n-zC99pnrihbCQokSh2J1jqf-MSEE$>
>> >
>> > Thanks,
>> > Filipp.
>>
>
More information about the hotspot-compiler-dev
mailing list