[151] in java-interest

home help back first fref pref prev next nref lref last post

Assertions (was Re: Overriding and an extention)

daemon@ATHENA.MIT.EDU (Robert S. Thau)
Tue May 30 12:12:59 1995

From: rst@ai.mit.edu (Robert S. Thau)
Date: Tue, 30 May 95 07:13:15 EDT
To: java-interest@java.Eng.Sun.COM

   From: Arthur.Vanhoff@eng.sun.com (Arthur van Hoff)
   Date: Mon, 29 May 1995 18:36:50 -0800 (PDT)

   > In addition, an assert() could be an optimisation hint to the
   > runtime.  For example, if you have:
   > 
   > void x(int len, int[] a)
   > {
   > 	assert(len < a.length);
   > 
   > 	for(int i = 0; i < len; i++)
   > 		dosomething(a[i]);
   > }
   > 
   > If it's clever enough, the runtime could see the assertion, and
   > therefore know that i is always going to be less than the array
   > length, and need not generate bounds check code for each loop
   > iteration.  Perhaps this isn't the best example, since the runtime
   > could do the same analysis with "for(int i = 0; i < a.length; i++)",
   > but an assertion may make it cheaper.  The analysis would have to
   > be rigorous either way, but the assertion could say whether the
   > runtime should bother or not.

   But how do we know that the caller of x follows the convention
   and makes sure that len is less than a.length? Somewhere we need
   to check. You can't eliminate the boundary check at compile time because
   the byte code verifier has to be able to come to the same conclusion
   before it can accept the code as legal.

You can't eliminate the range check completely, barring
interprocedural analysis, but you can at least hoist it out of the
loop itself.  That would seriously cut down on the expense of these
checks, which is, if I understand the situation right, the major
reason (along with null pointer checks, many of which could also be
hoisted) why native-compiled java still doesn't run as fast as C.

(As the base note points out, it would be even nicer to have a
compiler which figured out and inserted the required assertions for
itself; it would be interesting to know how hard that would be.  I'm
not a compiler jock, but I'll speculate anyway that it may not be too
much more difficult than using explicit assertions: in the code
fragment above, for instance, the actual subscript used is 'i', and
the compiler has to verify that that is bounded from above by 'len'
before it can make use of the 'assert'.  The Python compiler for CMU
Common Lisp does a lot of this sort of thing, including explicitly
tracking the possible value ranges of integer variables).

rst

-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com

home help back first fref pref prev next nref lref last post