AES-NI intrinsics enabled by default?

Question

Oracle has this to say about Java 8 with regards to AES-NI:

Hardware intrinsics were added to use Advanced Encryption Standard (AES). The UseAES and UseAESIntrinsics flags are available to enable the hardware-based AES intrinsics for Intel hardware. The hardware must be 2010 or newer Westmere hardware. For example, to enable hardware AES, use the following flags:

-XX:+UseAES -XX:+UseAESIntrinsics

To disable hardware AES use the following flags:

-XX:-UseAES -XX:-UseAESIntrinsics

But it does not indicate if AES intrinsics are enabled by default (for processors that support it). So the question is simple: if the processor supports AES-NI, are AES intrinsics used?

Bonus question: is there any way to test if AES-NI is being used? I guess you can guess based on performance, but that's not an optimal or sure fire way of testing.

---

For readerS that are not familiar with AES-NI intrinsics: it's replacing byte code with pre-compiled machine code, using the AES-NI instruction set. This happens by the JVM, so it does not show up in the API of the Java runtime or bytecode.

Annihilation

Answer 1

The flag has a default of true and it will be set to false if the detection fails, so you can simply use +PrintFlagsFinal to see if it is used:

My Laptop without AES-NI:

C:\>"C:\Program Files\Java\jdk1.7.0_51\bin\java" -XX:+PrintFlagsFinal -version | find "UseAES"
     bool UseAES                                    = false           {product}
     bool UseAESIntrinsics                          = false           {product}
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

Same on Desktop with AES-NI:

C:\>"C:\Program Files\Java\jdk7\bin\java" -XX:+PrintFlagsFinal -version | find "AES"
     bool UseAES                                    = true            {product}
     bool UseAESIntrinsics                          = true            {product}

java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

C:\>"C:\Program Files (x86)\Java\jre7\bin\java" -XX:+PrintFlagsFinal -version | find "AES"
     bool UseAES                                    = true            {product}
     bool UseAESIntrinsics                          = true            {product}

java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) Client VM (build 24.51-b03, mixed mode, sharing)

So, it works for both x64 and i686 (WOW64) with recent Java 7. The feature was introduced with https://bugs.openjdk.java.net/browse/JDK-7184394 and backported to 7u40 and 7u45.

---

Important: AES-NI may only be available on the server VM.

This was acknowledged by Oracle after a bug report was filed. This vital piece of information was missing when they created the featues list of Java 8 where it was introduced (it later got backported to 7 as well). The server VM can be explicitly choosen by providing the -server option on the java or javaw command line.

Dagostino

Answer 2

This mailthread from openjdk says, all AES intrinsics are enabled by default. Although I'm not certain how much of the Oracle core VM code shares with openjdk. If you read the whole thread, they also discuss about challenges on 32-bit VMs, that probably explains your problem with your second test run.

• Regarding your test, don't you think the differences in the CPUs make a big difference? Core i7's are quadcore and have better clock speeds in general. Wouldn't that have made a difference ? I guess that shift from 21s (core i5, 32bitVM, AES-NI off) to 8s (core i7, 64bitVM, AES-NI off) is the difference between i5 and i7.
• The improvement from 8s to 3s, although not 7 fold, is indeed worth a 'Yipes'! :)
• Regarding the detection mechanism - there doesn't seem to be a straightforward way. JVM throws a warning "AES intrinsics not available on this CPU" if you enabled the flags, and if it cannot find AES support - as per this bug report.

Burnedout

AES CBC is strictly linear in nature, so multiple cores do not matter (and of course I run with a task scheduler or top enabled). Furthermore, on the i5 I can clearly see that there is no difference with regard to performance, enabled or disabled. Finally, it seems that the old check for additional CPU instructions was fixed in the bug report. I don't see anything conclusive to see why the older CPU is not supported. With the 7 fold increase: that was Java 8 running on i5 32 bit and newer i7 bit. Still huge increase for the same class bytes :) – Annihilation

Oh, and the i7 seemed to perform about 2x the speed of the i5 for normal applications (I've tested C++ compilation specifically) which is much faster, but not a 7 fold gap by a long way. Note that 64 bit optimized applications may get an additional speed up. Those newer CPU's do make a difference I guess. – Annihilation

Okay. Makes sense. In my own tests, the AES flags doesn't seem to be honored. No matter I enable or disable the flags, the execution times are the same. So, if we need the actual difference introduced by CPU support, we might need identical CPUs - one with disabled AES-NI and another enabled. One guy here has some interesting results (not java), with kernel disabling AES-NI : ask.fedoraproject.org/en/question/29298/… His results are very close to yours (7x in many cases) – Burnedout

I also noticed that java 8 brings in some improvement in the crypto libraries. For small tests (1k, 2k buffered AES-256 encryption), the execution times are 2x as compared to java 7. – Burnedout

There is a bug report that targets AES init using the same key - if the same key is used then it is not necessary to recalculate the key schedule for AES. But I thought that one was integrated earlier - it would however explain the difference in speeds with regards to small buffers - you could play around with Cipher.getInstance() and see if it makes a difference if the same instance is used or not. – Annihilation