Re: [Classpath] style question
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 ) ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Classpath] style question
"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().
I am not proposing to use VM hardware array bounds checking to reduce
the amount of bytecode. And I do agree that this:
try
{
int i = 0;
while (i++)
// process array[i]
}
catch (IndexOutOfBoundsException e)
{
// ignore - we used a try-catch as flow control
}
is much worse than this:
for (int i = 0; i < array.length; i++)
// process array[i]
> I can't imagine any
> case where the try-catch would be faster for array-bounds (okay, there are
> some w/in *imagination*, but...). In most cases, you'd be doing the same
> array-bounds tests in hardware as in the explicit case, but then you'd
> have to create the exception object and throw it, only to be caught,
> rebuilt as another exception object, and rethrown.
That's what I was asking - if anyone else thinks that my proposed change
in decode() is one of those situations.
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [Classpath] style question
On Sun, 24 Feb 2002, Eric Blake wrote: > Which is prefered, performing array bound checks throughout a method, or > enclosing the algorithm in a try-catch block which converts an > IndexOutOfBoundsException into a NumberFormatException? 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. The try-catch block technique is sometimes faster for NullPointer exceptions (because the exception handling is wrapped around the native hardware memory protection mechanisms, and thus no hardware instructions are required to do the checks in the common case), but I can't imagine any case where the try-catch would be faster for array-bounds (okay, there are some w/in *imagination*, but...). In most cases, you'd be doing the same array-bounds tests in hardware as in the explicit case, but then you'd have to create the exception object and throw it, only to be caught, rebuilt as another exception object, and rethrown. Style needn't have anything to do w/ efficiency, though. YMMV. --scott Legion of Doom AK-47 DNC Rijndael Qaddafi payment Bush explosives Kennedy Indonesia biowarfare AES plastique Attache Saddam Hussein ( http://lesser-magoo.lcs.mit.edu/~cananian ) ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
style question
I'm looking at fixing a bug in Long.decode(), and came across a style
question.
Which is prefered, performing array bound checks throughout a method, or
enclosing the algorithm in a try-catch block which converts an
IndexOutOfBoundsException into a NumberFormatException? Using a
try-catch block emits less bytecode, and if decode() is used on valid
strings as the common case, it reduces overhead to not check the
bounds. In the exceptional case, my proposal must create and discard an
IndexOutOfBoundsException, while bounds checking avoids that, but the
method fails in either case.
Here's a diff, (not quite to GNU coding standards, to preserve
indentation), that illustrates my question:
Index: java/lang/Long.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/Long.java,v
retrieving revision 1.14
diff -u -r1.14 Long.java
--- java/lang/Long.java 25 Feb 2002 01:36:03 - 1.14
+++ java/lang/Long.java 25 Feb 2002 06:38:54 -
@@ -355,27 +355,25 @@
[...]
public static Long decode(String str)
{
+try
+ {
boolean isNeg = false;
int index = 0;
int radix = 10;
-final int len;
-
-if ((len = str.length()) == 0)
- throw new NumberFormatException();
+final int len = str.length();
// Negative numbers are always radix 10.
if (str.charAt(0) == '-')
@@ -405,10 +403,13 @@
radix = 8;
}
-if (index >= len)
- throw new NumberFormatException();
-
+// Change parseLong to throw IndexOutOfBoundsException...
return new Long(parseLong(str, index, len, isNeg, radix));
+ }
+catch (IndexOutOfBoundsException e)
+ {
+throw new NumberFormatException();
+ }
}
/**
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
