Community
Participate
Working Groups
Created attachment 189173 [details] The java file containing the methods I have written a little class which does some simple calculations My expectation would have been that those calculations get optimized by the compiler. However this seems to be not the case Original: public int calc (int param) { return 100*param/100; } Actual result: return 100*param/100; Expected result: return param*100/100; or even better return param; Original: public int calc (int param) { return 100*param/200; } Actual result: return 100*param/200; Expected result: return param*0.5; Original: public int calc (int param) { return param*100/200; } Actual result: return param*100/200; Expected result: return param*0.5; Original: public int calc (int param) { return param*100/100; } Actual result: return param*100/100; Expected result: return param*1; or even better return param; Original: public int calc (int param) { return param*(100/200) } Actual result: return param*0 Expected result: return param*0 or even better return 0 Original: public int calc (int param) { return param*(100/100); } Actual result: return param*1; Expected result: return param*1; or even better return param
Created attachment 189174 [details] The compiled class file
Obviously this optimizations could be done for other primitive types as well. I checked for double and the results look similar. Some more test: public int calc7(int param) { return param * 0; } could be optimized directly to return 0; public double calc7(int param) { return param / 0; } could lead directly to a compiler error
With today's JITs, I am not sure this would change anything. Optimizing the compiler for such cases is not free. So it would impact all cases for a possible performance gain. Do you have numbers that would show the advantage of such optimization beside making the .class files smaller ?
(In reply to comment #0) > My expectation would have been that those calculations get optimized by the > compiler. However this seems to be not the case > Original: > public int calc (int param) { > return 100*param/100; > } > > Actual result: > return 100*param/100; > > Expected result: > return param*100/100; > > or even better > return param; My expectation is that an optimized program behaves equal to the original. But: int result = calc(Integer.MAX_VALUE); Saying: we should always be *very* careful about corner cases.
(In reply to comment #4) > My expectation is that an optimized program behaves equal to the original. > But: > > int result = calc(Integer.MAX_VALUE); > > Saying: we should always be *very* careful about corner cases. Plus you cannot optimize much if floating point computation is involved (see JLS 15.7.3)
Well, the point came up when investigating some performance issues on an android device. So I have no numbers for Java itself and it might be very well the case that such stuff should be done on Android level. I agree that this is not for free. In the end I cannot judge how much performance this will cost during compile time and how much we will gain during runtime.
Not only this is not free, but it would be wrong in some cases. param / 0 must lead to an runtime exception. This is not a compile error. And as Stephan pointed out: public class X { public static int calc (int param) { return 100*param/100; } public static void main(String[] args) { System.out.println(calc(Integer.MAX_VALUE)); } } => -1 and not Integer.MAX_VALUE. Srikanth, I am tempted to close as WONTFIX.
(In reply to comment #7) > Srikanth, I am tempted to close as WONTFIX. Agree with assessment. Resolving as WONTFIX.
Verified for 3.7 M7.
