[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