RFR: 8231955: ARM32: Address displacement is 0 for volatile field access because of Unsafe field access.

[dean.long at oracle.com]

I see now that BarrierSetC1::resolve_address() is calling 
generate_address(), at least when access isn't patched.  So now I'm 
thinking that the address passed to 
volatile_field_load/volatile_field_store should be correct, and the call 
to add_large_constant() isn't necessary.

dl

On 10/24/19 5:37 PM, dean.long at oracle.com wrote:
> The shared code used to call generate_address(), which correctly 
> handles various displacements, but I guess it got lost in the barrier 
> refactoring in jdk11.  I think the correct fix is for the caller to 
> use generate_address() again.  CCing GC alias. Alternatively, the arm 
> code could call generate_address rather than changing the shared code.
>
> dl
>
> On 10/15/19 12:30 AM, christoph.goettschkes at microdoc.com wrote:
>> Is there anyone who could take a look at this change and give feedback
>> please?
>>
>> Thanks,
>> Christoph
>>
>> "hotspot-compiler-dev" <hotspot-compiler-dev-bounces at openjdk.java.net>
>> wrote on 2019-10-10 16:29:11:
>>
>>> From: christoph.goettschkes at microdoc.com
>>> To: hotspot-compiler-dev at openjdk.java.net
>>> Date: 2019-10-10 16:35
>>> Subject: RFR: 8231955: ARM32: Address displacement is 0 for volatile
>> field
>>> access because of Unsafe field access.
>>> Sent by: "hotspot-compiler-dev"
>> <hotspot-compiler-dev-bounces at openjdk.java.net>
>>> Hi,
>>>
>>> please review the following changeset. This patch fixes the volatile
>> field
>>> access for 32-bit ARM. The functions LIRGenerator::volatile_field_store
>>> and LIRGenerator::volatile_field_load both assume that the displacement
>>> for the given address is always 0. Both use the given address and pass
>> the
>>> values to add_large_constant() [1], which asserts that the given
>>> displacement is not 0. The change does not call add_large_constant if
>> the
>>> given displacement is 0. The displacement can be 0, because of the
>>> implementation of the unsafe intrinsics. This happens, because the
>> offset
>>> into the object from which the field is accessed is not a constant
>> value.
>>> This fixes the hotspot tier1 tests mentioned in the issue.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231955
>>> Webrev: https://cr.openjdk.java.net/~bulasevich/8231955/webrev.00/
>>>
>>> Thanks,
>>> Christoph
>>>
>>> [1]
>>>
>> https://hg.openjdk.java.net/jdk/jdk/file/30a9612a657d/src/hotspot/cpu/arm/ 
>>
>>> c1_LIRGenerator_arm.cpp#l166
>>>
>