cost of Java "assert" when disabled?

[Dmitry Samersoff]

Ramki,

Please notice:

a)
asserts causes new object allocation, stackmaptable and exception table
grows.

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


b)
   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;

c)
  code below

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

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

 so you have to write

 try{
  assert false : "False";
 }
 catch(AssertionError ex){
   System.err.println(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.


-Dmitry


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 ...