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
Fri May 31 11:52:41 PDT 2013

On 2013-05-31, at 1:43 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> On 5/31/13 7:42 AM, David Chase wrote:
>> The current plumbing for the XX option does affect code flow in the compiled C; that was pretty much the entire point of it.  Vladimir has a plan, I think his attitude is that if convert this into an intrinsic then we won't care about compiler version or updating the code to get rid of the assembler, it will just be done, for good.  My POV is that for now it's done, and we don't have to touch it for a good long while (except that I left Windows unoptimized).
> My biggest concern about the assembler code in jdk is its support. Even if you document how you got ".byte  0xc4,0xe3", next person will have very hard time to fix/modify this code. From my point of view it is dead code.

To modify it would be to break it :-).

I see this mostly as a matter of division of concerns; the only reason I know of to modify it would be if the scheduling on some future processor was radically different; I did get different code from clang and gcc, but not substantially different, and I could not tell if there was a reliable difference in run times.  Unless we put ourselves in the business of knowing how those particular intrinsics like to be scheduled on different processors -- and I cannot see that being worth our time unless there is a huge difference -- I assume we're going to be about as inflexible as pre-compiled assembly language, and if a big change occurs, by then we can recompile the C code.

And unless we plan to derive the schedule algorithmically, even if we do generate specific schedules for specific machines, we'll probably just have them canned in the compiler -- probably a larger text footprint than just precompiling both versions of the code and choosing a function pointer to the better one at runtime.

> About intrinsic. It will work on all OSs (including Windows) and don't need special versions of gcc, c++. But, it looks like, I need an other week to finish it. And I am worried about startup performance of intrinsic vs asm in jdk.

It would be nice if we updated the reference versions of the compilers for jdk8, so that they were no longer "special".


More information about the hotspot-compiler-dev mailing list