Role of cache in autoboxing

Question

Item 5 in Effective Java Joshua Bloch says avoid creating your object pool unless the objects are extremely heavy weight but in jdk source I see IntergerCache in Integer class, LongCache and CharacterCache in Long and Character class.

    public class autobox {

        /**
         * @param args
         */
        public static void main(String[] args) {
            long start=System.nanoTime();
            Integer sum=0;
            sum=sum+94;  //1-- takes most time
            long end=System.nanoTime();
            System.out.println(end-start);
            for(int i=0;i<1000;i++)
                sum=sum+i;
            end=System.nanoTime();
            System.out.println(end-start);  //--2
            sum=0;
            for(int j=5;j<1000;j++)
                sum=sum+j;
            end=System.nanoTime();
            System.out.println(end-start);  //--3
        }
    }

Output on my machine (with Java SE 1.7)

540686
984338
1450849

It looks like statement 1 is creating a too many objects all for the sake of creating just one Integer object!. I don't get the reason behind this. Though the documentation mentions -XX:AutoBoxCacheMax=<size> I get an error Unrecognized VM option 'AutoBoxCacheMax=0'. Shouldn't the cache only keep created objects instead of creating unnecessary objects?

Why are you using the wrapper types? `int sum=0;` would be a performant way to do that, and that is why Java has primitive types. — Elliott Frisch, Apr 11 '14 at 19:03
That's just a sample program..not a requirement.But there could be one..say if i have to put it as a value in HashMap — rakesh99, Apr 11 '14 at 19:11
Sounds like [premature optimization](http://c2.com/cgi/wiki?PrematureOptimization) to me. — Elliott Frisch, Apr 11 '14 at 19:13
The cache is created only once per _program_, when you load the `Integer` class. (And checking to see if the cache already contains an object can be more expensive than just creating the entire cache all the way full.) — Louis Wasserman, Apr 11 '14 at 19:17
Because it is a wrapper rather than a primitive, its doing extra work to do the same task. Now, for your requirement of HashMap, you cannot give primitives. So, you cannot optimize there. — bgth, Apr 11 '14 at 19:17

score 0 · Answer 1 · edited May 23 '17 at 12:21

You are not in control of what you are measuring. Please take a look here on how to do a correct micro benchmark in java.

1) In your code you have:

1      long start=System.nanoTime();
2      Integer sum=0;
3      sum=sum+94;  //1-- takes most time
4      long end=System.nanoTime();

Where you assume line 3 takes a lot of time. Actually it's line 2 (see below).

2) You System.out.println(...) is included in the 2. and 3. time measure. This is a problem, as printing to console is quite expensive and should be eliminated from your measurement.

To illustrate I have rearranged your code and get quite different measures:

    long start;
    long end;

    start=System.nanoTime();
    System.out.println("println test");
    end = System.nanoTime();
    System.out.println("Time 1: " + (end - start));

    start=System.nanoTime();
    Integer sum=0;
    end = System.nanoTime();
    System.out.println("Time 2: " + (end - start));

    start=System.nanoTime();
    sum=sum+94;
    end = System.nanoTime();
    System.out.println("Time 3: " + (end - start));

    start=System.nanoTime();
    for(int i=0;i<1000;i++) {
        sum=sum+i;
    }
    end = System.nanoTime();
    System.out.println("Time 4: " + (end - start));

    sum=0;
    start=System.nanoTime();
    for(int j=5;j<1000;j++) {
        sum=sum+j;
    }
    end=System.nanoTime();

    System.out.println("Time 5: " + (end - start));

Output:

println test
Time 1: 140572
Time 2: 360759
Time 3: 3420
Time 4: 139639
Time 5: 130619

And then again, please don't read too much into these numbers. This is a test without a popper warm-up phase, and with no consideration for the effect of JIT compilation etc.

Role of cache in autoboxing

1 Answers1