On Jun 15, 2011, at 5:26 PM, Rémi Forax wrote:
> 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
How do I build this thing? -- Christian
>
> 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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
