Re: [Classpath] style question

[C. Scott Ananian]

On Mon, 25 Feb 2002, Eric Blake wrote:

> "C. Scott Ananian" wrote:
> > 
> > For what it's worth: often adding explicit bounds checks will enable the
> > compiler to create faster code (by hoisting these checks, and others which
> > are implicit in the java semantics, out of the loop).  I'm not sure
> > which/any of the existing Java compilers are smart enough to do this, but
> > they all will be, eventually.
> 
> Notice that in my case, though, there is no loop, and the bounds check
> is still in software.  I'm simply proposing to remove two independent
> checks of the length in decode(), (before parsing, and after parsing
> "0x"), because they duplicated the bounds check already explicit in
> String.charAt().

What I was saying, in effect, was that duplicate array bounds checks
should be optimized away, *if the compiler can determine that they are, in
fact, duplicate*.  Using the try-catch construct obscures this fact, so it
makes it harder for the compiler to Do The Right Thing.  Ideally, a
compiler would a) inline String.charAt(), b) remove the check from the
inlined String.charAt() since it was dominated by a similar check, and c)
then remove the second bounds check in decode, for the same reason as b).

I'm pretty sure the MIT FLEX compiler can do this, for example.
There are so many duplicate checks implicit in the java semantics that
most compilers would/should optimize them away.
  --scott

PLO AP Cocaine Boston Hussein Albanian assassination politics RNC 
munitions Kojarena plastique Serbian Rule Psix President planning 
              ( http://lesser-magoo.lcs.mit.edu/~cananian )