I've just finished to code a sample for the cookbook that does integer operation (+ and -) with overflow (to BigInteger).
https://code.google.com/p/jsr292-cookbook/source/browse/#svn%2Ftrunk%2Fbinary-operation%2Fsrc%2Fjsr292%2Fcookbook%2Fbinop For a code like this one: max = ... for(i=0; i<max; i = i + 1) { // do nothing } i + 1 is transformed to: if (i.getClass() == Integer.class) { int j = i.intValue(); if (j != MAXINT) { i = Integer.valueOf(j + 1); } else { fallback(); } } else { fallback(); } but there is a bad news, perf of i + 1 considering 1 as a constant are *worst* (2 or 3 times !!) that using the double xor trick. // with the optimization [forax@localhost binary-operation]$ time java -cp .:classes PerfOpt real 0m0.954s user 0m1.030s sys 0m0.087s // without [forax@localhost binary-operation]$ time java -cp .:classes Perf real 0m0.378s user 0m0.407s sys 0m0.081s Knowing that the double xor trick does 4 comparisons and the constant trick only two, the problem comes from either my code or the way the VM inlines the method handles. I've found no problem in my code so ... :) Playing with the VM logs, the method containing (j != MAXINT) is not inlined because it hits the maximum depth (as far as I remember this problem is new, the older algorithm, the one that didn't propagate MDO, didn't exhibit this problem). Moreover, the VM tries to inline some parts of the fallback method (twice :( ) even if this code never called. The way the VM decides to inline method handles in this case is not good at all. Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
