Speaking in more conferences ;)

There has been a lack of updates on this blog.. yes… I’m fully aware. But I’ve been speaking in some more conferences (like if that was a good excuse…). For example, last weekend, I spoke at the first edition of JBCNConf here in Barcelona about Java performance and basically what’s going on at compiler level when we compile java code.
Click here or the image below for the slides.
Screen Shot 2015-06-28 at 21.45.54

BcnDevCon Presentation – Improving Java & Dalvik Code Performance

Last week I did a presentation at BcnDevCon about improving Java Code Performance. The focus of the presentation was showing some examples of compiled java sources and evaluate the performance impact of different ways of looping, string concatenation or using Java 1.5 features as autoboxing or foreach loops. According to java the performance optimizations are always left to the JVM, but we will see we can do many things to improve our code performance by knowing how the compiler works.
Some of these examples are also shown on Davlvik bytecode and performance tests are executed on both a computer and an android device. Even if Dalvik is register based and standard java bytecode is stack base in general terms what works for standard java can be also applied for Android apps.
On future posts I will explain in more detail the performance graphs and other topics I didn’t had time to include in the presentation.
Screen Shot 2013-11-15 at 00.51.53

What your mom didn't tell you about autoboxing…

Autoboxing is a nice feature added to Java 5 to avoid writing boxing code to add, for example, primitive data types to a Collection as you can only add the appropriate wrapper class (Integer for int, Long for long, …). I’ve recently seen the autoboxing feature being widely used all over the place so I decided to write this post.
Oracle itself warns that “It is plenty fast enough for occasional use, but it would be folly to use it in a performance critical inner loop.” and “An Integer is not a substitute for an int; autoboxing and unboxing blur the distinction between primitive types and reference types, but they do not eliminate it.“. So that basically means do not use autoboxing on portions of code where performance counts.
To illustrate the problem I’ve written an example:

public class Autoboxing {
// method using "accidentally" autoboxing
public void method1() {
long t = System.currentTimeMillis();
Long total = 0l;
for(Integer i = 0; i < 10000000; i++) {
total += i;
System.out.println(" total method1: " + total + " time:" + (System.currentTimeMillis() - t));
// method not using autoboxing
public void method2() {
long t = System.currentTimeMillis();
long total = 0;
for(int i = 0; i < 10000000; i++) {
total += i;
System.out.println(" total method2: " + total + " time:" + (System.currentTimeMillis() - t));
public static void main(String[] args) {
Autoboxing abox = new Autoboxing();

The first method method1 uses some autoboxing (the Integer and the Long). The second method method2 only uses primitive data types. Both methods iterate 1.000.000 times and when they finish they print the total and the amount of milliseconds since they started.
The bytecode of the for loop of both methods already indicates, subtly, that method2 will be more efficient:
Bytecode for loop method1:

9: iconst_0
10: invokestatic #4; //Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
13: astore 4
15: aload 4
17: invokevirtual #5; //Method java/lang/Integer.intValue:()I
20: ldc #6; //int 10000000
22: if_icmpge 65
25: aload_3
26: invokevirtual #7; //Method java/lang/Long.longValue:()J
29: aload 4
31: invokevirtual #5; //Method java/lang/Integer.intValue:()I
34: i2l
35: ladd
36: invokestatic #3; //Method java/lang/Long.valueOf:(J)Ljava/lang/Long;
39: astore_3
40: aload 4
42: astore 5
44: aload 4
46: invokevirtual #5; //Method java/lang/Integer.intValue:()I
49: iconst_1
50: iadd
51: invokestatic #4; //Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
54: dup
55: astore 4
57: astore 6
59: aload 5
61: pop
62: goto 15

Bytecode for loop method2:

4: lconst_0
5: lstore_3
6: iconst_0
7: istore 5
9: iload 5
11: ldc #6; //int 10000000
13: if_icmpge 28
16: lload_3
17: iload 5
19: i2l
20: ladd
21: lstore_3
22: iinc 5, 1
25: goto 9

In terms of timing, if we execute this class we get the following result:

rrafols$ java Autoboxing
total method1: 49999995000000 time:110
total method2: 49999995000000 time:9

So method2 takes only 8.18% of the total time of method1. Pretty big difference huh?
What happens if we run the same without enabling the JIT (Just in Time compiler)? Most mobile devices have very limited or non-existent JIT.

rrafols$ java -Xint Autoboxing
total method1: 49999995000000 time:7387
total method2: 49999995000000 time:141

Method2 takes only 1.91% of the total time of method1. Not only that, imagine we’re processing something that we have to show back to the user, there is a huge impact between having the user to wait for ~8 seconds or to wait for 150ms.
Please use common sense and be extra careful when using code you are actually not controlling or the compiler is generating for you.

Presentation about Java Internals & Java code injection

Usually on Friday afternoons, while having a social drink, we do some technical presentations to share our knowledge to other colleagues.
One of the presentations I did was about Java internals, class file format, bytecode and some code injection I had to do. The funny part was after all the work, the ‘hack’ was not really needed, but I actually learned quite a lot.
Here you can find the slides:
Screen Shot 2013-03-28 at 10.32.08 AM
Slides (.pdf)