Assert & Bytecode & Assembly

This is the first of a series of posts that shows how certain language features and compiler optimisations are implemented on the JVM; on bytecode level and the Assembly emitted by the JIT. There are many blogposts/articles/presentation telling that these optimisations are done, but don't explain what is happening under the hood. So if you don't like to get your hands dirty, please move along.

I have been inspired to start blogging again by people like Gil Tene, Martin Thompson, Nits Wakart, Peter Lawrey, Cliff Click and many others. They provide so much insights of low level performance issues to the community, that I want to contribute as well.

Java assert

Java asserts have been added to Java 1.4 and are an easy way to check preconditions, postconditions and invariants. A nice feature of asserts is that they can easily be enabled/disabled either globally using `-da` but can also be disabled on package or class level. For more information see the following page.

Lets have a look at the following example:

public class Assert {

    public static void main(String[] args) {
        long l = 0;
        for (int k = 0; k < 100_000; k++) {
            l += twice(k);
        }
        System.out.println(l);
    }

    public static int twice(int a) {
        assert a != 0 : "a can't be 0";
        return a * 2;
    }
}

We have a loop that does a simple calculation. We also store the result and print it so that the JIT doesn't apply dead code elimination. In the 'twice' method there is a simple assert that checks if 'a' is not 0. The assert condition isn't very important, its primary function is to give easy to understand Assembly.

If we compile the code and output the content of the class it using 'javap -c Assert.class', we get the following bytecode:

public class com.asserts.Assert {
  static final boolean $assertionsDisabled;

  public com.asserts.Assert();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: lconst_0
       1: lstore_1
       2: iconst_0
       3: istore_3
       4: iload_3
       5: ldc           #2                  // int 100000
       7: if_icmpge     24
      10: lload_1
      11: iload_3
      12: invokestatic  #3                  // Method twice:(I)I
      15: i2l
      16: ladd
      17: lstore_1
      18: iinc          3, 1
      21: goto          4
      24: getstatic     #4                  // Field java/lang/System.out:Ljava/io/PrintStream;
      27: lload_1
      28: invokevirtual #5                  // Method java/io/PrintStream.println:(J)V
      31: return

  public static int twice(int);
    Code:
       0: getstatic     #6                  // Field $assertionsDisabled:Z
       3: ifne          20
       6: iload_0
       7: ifeq          20
      10: new           #7                  // class java/lang/AssertionError
      13: dup
      14: ldc           #8                  // String a can't be 0
      16: invokespecial #9                  // Method java/lang/AssertionError."":(Ljava/lang/Object;)V
      19: athrow
      20: iload_0
      21: iconst_2
      22: imul
      23: ireturn

  static {};
    Code:
       0: ldc           #10                 // class com/asserts/Assert
       2: invokevirtual #11                 // Method java/lang/Class.desiredAssertionStatus:()Z
       5: ifne          12
       8: iconst_1
       9: goto          13
      12: iconst_0
      13: putstatic     #6                  // Field $assertionsDisabled:Z
      16: return
}

It is interesting to see how the assert has been implemented. A new synthetic static final field `$assertionsDisabled` has been added to the class which gets initialized when the class is loaded. See the 'static {}' for more detail.

The first instruction of the `twice` method loads this static field and then there is a check if this field is set. If `$assertionsDisabledis` false, it continues with the assert statement on #6. If `$assertionsDisabled` is true (so assert disabled), then there is a jump to the actual logic on #20.

If we convert the 'twice' bytecode back to Java, we would get:

public class Assert {

    static final boolean $assertionsDisabled;
 
    public static int twice(int a) {
        if(!$assertionsDisabled){
          if(a == 0) {
            throw new AssertError("a can't be 0")
          }
        }
        return a * 2;
    }
}

So the assert doesn't require any special new bytecode instructions. It is translated to a few simple checks.

Assert disabled

As a performance engineer, I'm always worried if we need to pay the price for something that isn't used. In this case, on the bytecode level, there is one extra branch to deal with when assertions are disabled and 2 branches when assertions are enabled. Till so far I'm not terribly excited since branching and high performance code, is not really a good mixture.

So lets see if the JIT can optimize it if assertions are disabled. For this I'm using the following commands:

-XX:+UnlockDiagnosticVMOptions
-XX:PrintAssemblyOptions=intel
-XX:-TieredCompilation
-XX:-Inline
-XX:CompileCommand=print,*Assert.twice

The TieredCompilation is disabled so we only get the C2 Assembly output. Inlining is disabled so that the 'twice' method doesn't get inlined in the main loop.

This provides us the following output:

Compiled method (c2)     190    8             com.asserts.Assert::twice (24 bytes)
 total in heap  [0x0000000101d7f310,0x0000000101d7f4e0] = 464
 relocation     [0x0000000101d7f430,0x0000000101d7f438] = 8
 main code      [0x0000000101d7f440,0x0000000101d7f460] = 32
 stub code      [0x0000000101d7f460,0x0000000101d7f478] = 24
 oops           [0x0000000101d7f478,0x0000000101d7f480] = 8
 metadata       [0x0000000101d7f480,0x0000000101d7f488] = 8
 scopes data    [0x0000000101d7f488,0x0000000101d7f498] = 16
 scopes pcs     [0x0000000101d7f498,0x0000000101d7f4d8] = 64
 dependencies   [0x0000000101d7f4d8,0x0000000101d7f4e0] = 8
Loaded disassembler from /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/hsdis-amd64.dylib
Decoding compiled method 0x0000000101d7f310:
Code:
[Disassembling for mach='i386:x86-64']
[Entry Point]
[Verified Entry Point]
[Constants]
  # {method} {0x00000001ca2ba4f8} 'twice' '(I)I' in 'com/asserts/Assert'
  # parm0:    rsi       = int
  #           [sp+0x20]  (sp of caller)
  0x0000000101d7f440: sub    rsp,0x18
  0x0000000101d7f447: mov    QWORD PTR [rsp+0x10],rbp  ;*synchronization entry
                                                ; - com.asserts.Assert::twice@-1 (line 14)

  0x0000000101d7f44c: mov    eax,esi
  0x0000000101d7f44e: shl    eax,1              ;*imul
                                                ; - com.asserts.Assert::twice@22 (line 15)

  0x0000000101d7f450: add    rsp,0x10
  0x0000000101d7f454: pop    rbp
  0x0000000101d7f455: test   DWORD PTR [rip+0xfffffffffe87fba5],eax        # 0x00000001005ff000
                                                ;   {poll_return}
  0x0000000101d7f45b: ret    
  0x0000000101d7f45c: hlt    
  0x0000000101d7f45d: hlt    
  0x0000000101d7f45e: hlt    
  0x0000000101d7f45f: hlt    
[Exception Handler]
[Stub Code]
  0x0000000101d7f460: jmp    0x0000000101d70f60  ;   {no_reloc}
[Deopt Handler Code]
  0x0000000101d7f465: call   0x0000000101d7f46a
  0x0000000101d7f46a: sub    QWORD PTR [rsp],0x5
  0x0000000101d7f46f: jmp    0x0000000101d4bd00  ;   {runtime_call}
  0x0000000101d7f474: hlt    
  0x0000000101d7f475: hlt    
  0x0000000101d7f476: hlt    
  0x0000000101d7f477: hlt    
OopMapSet contains 0 OopMaps  

There is quite a lot of output. If we only focus on the logic of the method and strip all ceremony, the following instructions remain:

  0x0000000101d7f44c: mov    eax,esi
  0x0000000101d7f44e: shl    eax,1              ;*imul
                                                 ; - com.asserts.Assert::twice@22 (line 15)

The 'a' argument (stored in register esi) is copied into the eax register. Then we multiply the eax register by shifting the bits one to the left and store the result back into eax register. The eax register will be used to access the return value. Replacing the multiply by a shift left is a peephole optimization since bitshifting is faster than doing a multiply. The conclusion we can make is that if assert is disabled, the JIT completely removes the '$assertionsDisabled' check. That is good news; I hate to pay the price for something not used.

Assert enabled

What if assertions are enabled? For this we run with the following settings

-XX:+UnlockDiagnosticVMOptions
-XX:PrintAssemblyOptions=intel
-XX:-TieredCompilation
-XX:-Inline
-XX:-BackgroundCompilation
-XX:CompileCommand=print,*Assert.twice
-ea

And we get the following Assembly

Compiled method (c2)     168    8             com.asserts.Assert::twice (24 bytes)
 total in heap  [0x0000000109e7c310,0x0000000109e7c548] = 568
 relocation     [0x0000000109e7c430,0x0000000109e7c440] = 16
 main code      [0x0000000109e7c440,0x0000000109e7c480] = 64
 stub code      [0x0000000109e7c480,0x0000000109e7c498] = 24
 oops           [0x0000000109e7c498,0x0000000109e7c4a0] = 8
 metadata       [0x0000000109e7c4a0,0x0000000109e7c4a8] = 8
 scopes data    [0x0000000109e7c4a8,0x0000000109e7c4d0] = 40
 scopes pcs     [0x0000000109e7c4d0,0x0000000109e7c540] = 112
 dependencies   [0x0000000109e7c540,0x0000000109e7c548] = 8
Loaded disassembler from /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/hsdis-amd64.dylib
Decoding compiled method 0x0000000109e7c310:
Code:
[Disassembling for mach='i386:x86-64']
[Entry Point]
[Verified Entry Point]
[Constants]
  # {method} {0x000000011217a4f8} 'twice' '(I)I' in 'com/asserts/Assert'
  # parm0:    rsi       = int
  #           [sp+0x20]  (sp of caller)
  0x0000000109e7c440: mov    DWORD PTR [rsp-0x14000],eax
  0x0000000109e7c447: push   rbp
  0x0000000109e7c448: sub    rsp,0x10           ;*synchronization entry
                                                ; - com.asserts.Assert::twice@-1 (line 14)

  0x0000000109e7c44c: test   esi,esi
  0x0000000109e7c44e: je     0x0000000109e7c460  ;*ifne
                                                ; - com.asserts.Assert::twice@7 (line 14)

  0x0000000109e7c450: mov    eax,esi
  0x0000000109e7c452: shl    eax,1              ;*imul
                                                ; - com.asserts.Assert::twice@22 (line 15)

  0x0000000109e7c454: add    rsp,0x10
  0x0000000109e7c458: pop    rbp
  0x0000000109e7c459: test   DWORD PTR [rip+0xffffffffff6ecba1],eax        # 0x0000000109569000
                                                ;   {poll_return}
  0x0000000109e7c45f: ret    
  0x0000000109e7c460: mov    esi,0x7
  0x0000000109e7c465: xchg   ax,ax
  0x0000000109e7c467: call   0x0000000109e47120  ; OopMap{off=44}
                                                ;*new  ; - com.asserts.Assert::twice@10 (line 14)
                                                ;   {runtime_call}
  0x0000000109e7c46c: call   0x000000010898fe44  ;*new
                                                ; - com.asserts.Assert::twice@10 (line 14)
                                                ;   {runtime_call}
  0x0000000109e7c471: hlt    
  0x0000000109e7c472: hlt    
  0x0000000109e7c473: hlt    
  0x0000000109e7c474: hlt    
  0x0000000109e7c475: hlt    
  0x0000000109e7c476: hlt    
  0x0000000109e7c477: hlt    
  0x0000000109e7c478: hlt    
  0x0000000109e7c479: hlt    
  0x0000000109e7c47a: hlt    
  0x0000000109e7c47b: hlt    
  0x0000000109e7c47c: hlt    
  0x0000000109e7c47d: hlt    
  0x0000000109e7c47e: hlt    
  0x0000000109e7c47f: hlt    
[Exception Handler]
[Stub Code]
  0x0000000109e7c480: jmp    0x0000000109e6bf60  ;   {no_reloc}
[Deopt Handler Code]
  0x0000000109e7c485: call   0x0000000109e7c48a
  0x0000000109e7c48a: sub    QWORD PTR [rsp],0x5
  0x0000000109e7c48f: jmp    0x0000000109e46d00  ;   {runtime_call}
  0x0000000109e7c494: hlt    
  0x0000000109e7c495: hlt    
  0x0000000109e7c496: hlt    
  0x0000000109e7c497: hlt    
OopMapSet contains 1 OopMaps

#0 
OopMap{off=44}

Lets remove a lot of the clutter:

  0x0000000109e7c44c: test   esi,esi
  0x0000000109e7c44e: je     0x0000000109e7c460  ;*ifne
                                                ; - com.asserts.Assert::twice@7 (line 14)

  0x0000000109e7c450: mov    eax,esi
  0x0000000109e7c452: shl    eax,1              ;*imul
                                                ; - com.asserts.Assert::twice@22 (line 15)

  0x0000000109e7c454: add    rsp,0x10
  0x0000000109e7c458: pop    rbp
  0x0000000109e7c459: test   DWORD PTR [rip+0xffffffffff6ecba1],eax        # 0x0000000109569000
                                                ;   {poll_return}
  0x0000000109e7c45f: ret    
  0x0000000109e7c460: mov    esi,0x7
  0x0000000109e7c465: xchg   ax,ax
  0x0000000109e7c467: call   0x0000000109e47120  ; OopMap{off=44}
                                                ;*new  ; - com.asserts.Assert::twice@10 (line 14)
                                                ;   {runtime_call}
  0x0000000109e7c46c: call   0x000000010898fe44  ;*new
                                                ; - com.asserts.Assert::twice@10 (line 14)
                                                ;   {runtime_call}

This one is a bit more complicated. Lets start at `0x0000000109e7c44c` where a 'test esi,esi' is done. 'test esi,esi' checks if 'a' is 0 and updates the 'ZF' (Zero Flag) in the flags register. If ZF is 0, then we continue with the regular logic; we move 'a' in the 'eax' register and multiply it by 2 and then the procedure exit ceremony is executed. This is no different then when assert is disabled.

If ZF is 1 (so a==0), then we jump to `0x0000000109e7c460`. We are totally bypassing the regular logic and even fail to execute the exit ceremony for procedure. Everything we have done so far is frozen and then we shoot into space. The mechanism we are seeing is called the uncommon trap and required for speculative optimizations. In this case, we have never called `twice` with 0, so for the JIT there was no reason to emit the 'throw new AssertError' code. As soon as I figured out the handling of this uncommon trap, I'll create a blogpost about it.

If we would translate this back to Java, we would get something like:

public class Assert {

    public static int twice(int a) {
        if(a == 0) {
            uncommonTrap();
        }
        return a * 2;
    }
}

If 'twice' would be called with 0, the uncommon trap gets executed, the code deoptimized and the interpreter will continue execution with the 'throw new AssertError' in place.

The conclusion we can make is: if assert is enabled, then the '$assertionsDisabled' check is removed.

Size matters

Till so far we have seen that the JIT completely removed all assert logic if assert is disabled. So it looks like assert is completely free if disabled. Unfortunately that isn't the case. The extra instructions inserted in the bytecode, can prevent inlining because inline limits are determined on the size of the bytecode.

Lets proof this by inflating the assert logic with some bogus additional conditions:

public class AssertFat {

    public static void main(String[] args) {
        long l = 0;
        for (int k = 1; k < 100_000; k++) {
            l += twice(k);
        }
        System.out.println(l);
    }

    public static int twice(int a) {
        assert a != 0 && a != -1 && a != -2 && a != -3 : "bad a";
        return a * 2;
    }
}

We have inflated the size of the assert artificially by adding some additional bogus checks.

If we would set the FreqInlineSize to 50, the method will not get inlined even when asserts are disabled:

-XX:+UnlockDiagnosticVMOptions 
-XX:+PrintInlining 
-XX:FreqInlineSize=50 
-da

In the logging we'll see the following in the inlining output:

    @ 12   com.asserts.AssertFat::twice (53 bytes)   callee is too large

This means that the `twice` method, 53 bytes, was too fat to get inlined since the maximum size for a frequently called method was set to 50 bytes.

To proof that the twice method would have been inlined without assert, lets remove the assert and run again:

@ 12   com.asserts.AssertFat::twice (4 bytes)

Now the method does get inlined.

This means that even though the JIT is able to completely remove the assert code if assert is disabled, it can still prevent inlining. Therefor the assert feature isn't completely free. It doesn't mean that you should remove assert from your code; but it is good to keep in the back of your mind.