cost of Java "assert" when disabled?

Dmitry Samersoff Dmitry.Samersoff at
Fri Feb 17 10:49:09 UTC 2012


Please notice:

asserts causes new object allocation, stackmaptable and exception table

Bytecodes for:
     int value = 10;
     assert false : value;

   0:	bipush	10
   2:	istore_1
   3:	getstatic	#2; //Field $assertionsDisabled:Z
   6:	ifne	18
   9:	new	        #3; //class java/lang/AssertionError
   12:	dup
   13:	iload_1
   14:	invokespecial	
                #4; //Method java/lang/AssertionError."<init>":(I)V
   17:	athrow

   assert MyClass.openFile();

   cause that openFile() will never be executed if assertions
   is disabled.

   So you  have to write:

      bool value = MyClass.openFile();
      assert value;

  code below

   assert false : System.err.println("False");

  will not ever compile, because System.err.println is void.

 so you have to write

  assert false : "False";
 catch(AssertionError ex){

and then rely on C1/C2 to eliminate useless code.

** IMHO, counting all above it's better to write your own function
MyAssert doing exactly what you need rather than use build-in one.

** Sidestepping to conditional compilation - I vote for it
with both hands.


On 2012-02-17 00:42, Srinivas Ramakrishna wrote:
> A Java language newbie question:
> Does anyone have any ballpark numbers on the cost (and its scaling) of
> peppering assert's in your Java code, but with asserts disabled (-da) ?
> In other words, is the disabled cost so vanishingly small that we need
> not think twice when using them, or should one be
> careful because the cost is non-negligible and can affect (bytecode)
> footprint or rutime performace even when switched off?
> thanks for any advice.
> -- ramki

Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...

More information about the core-libs-dev mailing list