[9] RFR (L) 8143012: CRC32 Intrinsics support on SPARC
Ahmed Khawaja
ahmed.khawaja at oracle.com
Fri Nov 20 15:55:03 UTC 2015
By having separate tables it gives us the freedom to use different types
of loads, which is something we are interested in doing in the future
(possibly when newer instructions are available) and merging them now
would only make that more difficult in the future. Also I believe the
way the code is written now, only one table is instantiated during
build/runtime, so there is no memory overhead. I believe keeping it as
is is advantageous from a code maintenance perspective and incurs no
overhead.
Ahmed
On 11/20/2015 9:51 AM, Vladimir Kozlov wrote:
> Are they really the same (little vs big endians)?
> We have crc32 implementation on other platforms too
>
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3b81bc9fe683
>
> Thanks,
> Vladimir
>
> On 11/20/15 7:41 AM, Roland Westrelin wrote:
>>> http://cr.openjdk.java.net/~kvn/8143012/webrev/
>>
>> That looks good to me but aren’t:
>>
>> Aren’t StubRoutines::Sparc::_crc_by128_masks[] and
>> StubRoutines::Sparc::_crc_table[] the same as
>> StubRoutines::x86::_crc_by128_masks[] and
>> StubRoutines::x86::_crc_table[] and can’t we do better?
>>
>> Roland.
>>
More information about the hotspot-compiler-dev
mailing list