[155] in java-interest
Re: Assertions (was Re: Overriding and an extention)
daemon@ATHENA.MIT.EDU (Arthur van Hoff)
Tue May 30 12:43:11 1995
Date: Tue, 30 May 1995 09:28:57 -0700
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
To: java-interest@java.Eng.Sun.COM
Hi Robert,
> 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.
Right, but you have to be careful not to do it too early. The byte code
verifier will have to redo all the work so that it can confirm that your
compiler did not get it wrong.
> (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).
Right again. This is a more interesting solution. Our native code generator
for example already does some simple data flow that is used to eliminate
null pointer checks. We can make it do the same for array bound checks.
Usually you would write:
for (int i = 0 ; i < arr.length ; i++) {
...
}
It is absolutely possible to generate the assertion from this code.
What I am trying to say is that assertions are useful as a debugging
tool, but they should not be used for compiler optimizations.
Have fun,
Arthur van Hoff (avh@eng.sun.com)
http://java.sun.com/people/avh/
Sun Microsystems Inc, M/S UPAL02-301,
100 Hamilton Avenue, Palo Alto CA 94301, USA
Tel: +1 415 473 7242, Fax: +1 415 473 7104
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
