RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

Vladimir Kozlov vladimir.kozlov at oracle.com
Sat Feb 14 00:29:28 UTC 2015


On 2/13/15 4:22 PM, Dean Long wrote:
> There is a system register bit to read, but I don't think it can be
> accessed by an application, only the kernel.
> If the OS won't provide this information, you could do something similar
> to safeFetchN and catch the
> resulting SIGBUS.

Yes, I agree it could be done this way too.
On x86 we trigger SEGV to verify that OS's signal handler correctly 
save/restore AVX registers so we can use them.

Vladimir

>
> dl
>
> On 2/13/2015 4:05 PM, Vladimir Kozlov wrote:
>> x86 has flag UseUnalignedLoadStores which is set to true depending on
>> which version of CPU VM runs. The CPU version is determined based on
>> CPUID instruction results.
>>
>> Does AARCH64 has something similar?
>>
>> Regards,
>> Vladimir
>>
>> On 2/13/15 3:41 PM, Dean Long wrote:
>>> On 2/13/2015 3:04 PM, christos at zoulas.com wrote:
>>>> On Feb 13,  2:52pm, dean.long at oracle.com (Dean Long) wrote:
>>>> -- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for
>>>> ByteBuffer
>>>>
>>>> | My understanding is that whether or not aarch64 allows unaligned=20
>>>> | accesses is based on a
>>>> | system setting, so this change is too simplistic.  I would prefer
>>>> that=20
>>>> | this was controlled with
>>>> | something more flexible, like "sun.cpu.unaligned".
>>>>
>>>> So does x86_64 and you can ask the CPU if it is enabled... I am not
>>>> sure
>>>> if a variable setting makes sense because if alignment is required you
>>>> get a signal (BUS error -- hi linux, SEGV), or incorrect results.
>>>>
>>>> christos
>>>
>>> So it sounds like we need to determine if unaligned accesses are
>>> supported during startup,
>>> in a platform-specific way.  This could be exposed through a property
>>> like I suggested,
>>> or perhaps a new Unsafe method.
>>>
>>> Regarding x86_64, there may be places in the JVM that already assume
>>> unaligned accesses
>>> are allowed, so disabling them may completely break the JVM until those
>>> assumptions
>>> are fixed.
>>>
>>> dl
>



More information about the core-libs-dev mailing list