RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

David Chase david.r.chase at oracle.com
Mon May 20 10:24:10 PDT 2013

PS, the code generated by Visual Studio 2012 from the C version of the source is nowhere near
as good as what comes from gcc 2.6 or clang.  Getting good code would require hand conversion
of 80 lines of assembler to the microsoft dialect, never mind the calling conventions.

That suggests disabling this optimization for Windows.


On 2013-05-20, at 1:14 PM, David Chase <david.r.chase at oracle.com> wrote:

> On 2013-05-20, at 11:28 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> On 5/20/13 6:49 AM, David Chase wrote:
>>> Suppose I split this bug (i.e., file a new bug) into the Intel-acceleration part and the fork-join part.
>> Yes, please, do that.
> And, before I waste more time tearing my hair out, suppose that I punt on accelerating Windows until we are using a more modern Visual Studio?
> Because I went a looked at the problem, the assembly language has a completely different syntax, it would double the amount of ugly asm in that file, and the people with the performance problem were not running Windows.
>> You still don't want to do it in VM as intrinsic/stubs? ;)
> I think that would be a lovely idea.
> Can we get 16-byte alignment guaranteed from the GCC, and use of 128-bit wide xmm registers compiled in?
>> You would not have all these C++ issues and I can help you with that.
> It is clear that the compiler internals are the land of don't-ask-don't-tell.
> Perhaps we could slip a little fork-join parallelism in there, too? :-)
> David

More information about the hotspot-compiler-dev mailing list