Eugene Ciurana

The JSR-223 sample code itself was a problem. It barely works, so it needs a lot of debugging before it can be trusted. For example, it couldn't find the class path, thus it couldn't find the standard libraries or the Scheme heap file, so I had to fix that. Other bugs and minor annoyances. The code from dev.java.net for JSR-223 sucks, both stylistically, in terms of maintenance, and in several cases in how it does its work. That's why this became a HOWNOT -- there's just too much grief in implementing a non-mainstream language for actual work. That's why the article explains the conditions when this is desired and why.

Hola.

Not a lot of JIT magic there. If you dump the .class file to JVM bytecodes, you will see that the compiler sets the space to be allocated when the method first enters scope, regardless of where in the method the variable was declared.

Outside:

<code>

public class Test {
public static void main(java.lang.String...) throws java.lang.Exception;
Code:
0: iconst_0
1: istore_2
2: iload_2
3: bipush 10
5: if_icmpge 28
8: iload_2
9: i2d
10: iload_2
11: i2d
12: iconst_2
13: iload_2
14: imul
15: i2d
16: invokestatic #2 // Method java/lang/Math.pow:(DD)D
19: dmul
20: d2i
21: istore_1
22: iinc 2, 1
25: goto 2
28: return
}

</code>

Inside:

<code>

public class Test {
public static void main(java.lang.String...) throws java.lang.Exception;
Code:
0: iconst_0
1: istore_1
2: iload_1
3: bipush 10
5: if_icmpge 28
8: iload_1
9: i2d
10: iload_1
11: i2d
12: iconst_2
13: iload_1
14: imul
15: i2d
16: invokestatic #2 // Method java/lang/Math.pow:(DD)D
19: dmul
20: d2i
21: istore_2
22: iinc 1, 1
25: goto 2
28: return
}

</code>

A better practice for new programmers, though, might be to remind them to not allocate/release resource-intensive objects in a loop. I was surprised to recently see some very slow code from experienced guys who did just that.

Anyway -- check your own code's behavior with:

<code>

javap -c YourClassFileHere.class

</code>

Cheers!

pr3d

Hola.

Not a lot of JIT magic there. If you dump the .class file to JVM bytecodes, you will see that the compiler sets the space to be allocated when the method first enters scope, regardless of where in the method the variable was declared.

Outside:

<code>

public class Test {
public static void main(java.lang.String...) throws java.lang.Exception;
Code:
0: iconst_0
1: istore_2
2: iload_2
3: bipush 10
5: if_icmpge 28
8: iload_2
9: i2d
10: iload_2
11: i2d
12: iconst_2
13: iload_2
14: imul
15: i2d
16: invokestatic #2 // Method java/lang/Math.pow:(DD)D
19: dmul
20: d2i
21: istore_1
22: iinc 2, 1
25: goto 2
28: return
}

</code>

Inside:

<code>

public class Test {
public static void main(java.lang.String...) throws java.lang.Exception;
Code:
0: iconst_0
1: istore_1
2: iload_1
3: bipush 10
5: if_icmpge 28
8: iload_1
9: i2d
10: iload_1
11: i2d
12: iconst_2
13: iload_1
14: imul
15: i2d
16: invokestatic #2 // Method java/lang/Math.pow:(DD)D
19: dmul
20: d2i
21: istore_2
22: iinc 1, 1
25: goto 2
28: return
}

</code>

A better practice for new programmers, though, might be to remind them to not allocate/release resource-intensive objects in a loop. I was surprised to recently see some very slow code from experienced guys who did just that.

Anyway -- check your own code's behavior with:

<code>

javap -c YourClassFileHere.class

</code>

Cheers!

pr3d

Joe - great write up. I wouldn't worry about the accuracy or fallacy of the benchmark. It doesn't matter how accurate it is, some troll will crawl from under a rock and claim that what you did it's wrong. I saw it happen with MuleMQ, for example, where first they were accused of hiding the benchmark, then of screwing it up when they published what they did (a standard benchmark at that; it wasn't home built or anything). So thanks for the results and for sharing them with us. Yey!

Arg! The end of the first sentence should say "without stopping it." Sorry about that and thanks! - now fixed.